EBS最適化インスタンスの効果を知るべくベンチマークを取ってみた

EBS最適化インスタンスの効果を知るべくベンチマークを取ってみた

Clock Icon2014.02.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

EC2で構成されたシステムのパフォーマンスを向上したい場合、一番簡単なのはインスタンスタイプを変更してスケールアップすることですが、ディスクI/Oがネックになっていることも多々あります。

EBSのパフォーマンス向上の手段としては大きく二つあります。

  1. EBS最適化インスタンス ... 通常EC2とEBS間の通信は他のネットワークトラフィックと共存していますが、EBS最適化(EBS optimization)インスタンスに設定することでEC2とEBS間に専用のネットワークスループットが確保され、他のネットワークトラフィックの影響を最小化することが出来ますので、EBSのパフォーマンスが安定的に引き出せます。
  2. Provisioned IOPS ... 作成時にIOPSレートを指定出来るボリュームです。最小200〜最大4000IOPSの範囲で指定可能です。なおその性質から上記のEBS最適化インスタンスと組み合わせて使用することが推奨されています。

さて、当然高いIOPSでプロビジョニングされたEBSはハイパフォーマンスに決まってますが、

  • この専用のネットワークスループットが確保されるEBS最適化インスタンスを設定しただけで、どのくらい性能差が出るものなんだろう?
  • 他のネットワークトラフィックというのはどの程度影響があるものなのだろう?

というのが、今回のスタート地点です。

ベンチマークの対象

EBS最適化インスタンスは以下のインスタンスタイプが使用出来ます。今回は1000Mbpsの帯域を確保可能なm1.xlargeにしました。

インスタンスタイプ 帯域
m1.large 500 Mbps
m1.xlarge 1000 Mbps
m2.2xlarge 500 Mbps
m2.4xlarge 1000 Mbps
m3.xlarge 500 Mbps
m3.2xlarge 1000 Mbps
c1.xlarge 1000 Mbps

また、EBS最適化インスタンスの検証は、それなりにネットワークトラフィックが高い状況で無いと確認が出来ません。そこでもう1台EC2を起動し、abでHTTPリクエストをガンガン掛けておきます。構成と結果予想は以下のような感じです。

プレゼンテーション1

ベンチマークの準備

今回のベンチマークはド定番であるところのfioを使用しました。

作成したEBSをext4、inode=512でmkfsし、特にオプションを付与すること無く普通にマウントします。

$ sudo mkfs.ext4 -I 512 /dev/xvdj
$ sudo mkdir /mnt/standard
$ sudo mount /dev/xvdj /mnt/standard

fioをインストールします。

$ sudo yum -y install rpm-build libaio-devel gcc make
$ wget http://pkgs.repoforge.org/fio/fio-2.1.4-1.rf.src.rpm
$ rpmbuild --rebuild fio-2.1.4-1.rf.src.rpm
$ sudo rpm -Uvh rpmbuild/RPMS/x86_64/fio-2.1.4-1.amzn1.x86_64.rpm 

fioは以下のようなオプションで実行しました。sequential read/write、random read/writeの4パターンで、O_DIRECTアクセスでブロックサイズを16KB、計測に使うファイルサイズを12GB、並列ジョブを64個にして、1分間実行します。

$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=read -bs=16k -size=12G -group_reporting -name=seqread -numjobs=64 -runtime=60 
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=write -bs=16k -size=12G -group_reporting -name=seqwrite -numjobs=64 -runtime=60 
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=randread -bs=16k -size=12G -group_reporting -name=randread -numjobs=64 -runtime=60 
$ fio -filename=/mnt/standard/testfio.file -direct=1 -rw=randwrite -bs=16k -size=12G -group_reporting -name=randwrite -numjobs=64 -runtime=60 

実行中は妨害EC2から以下のようにabを実行しネットワーク負荷を掛けます。index.htmlのファイルサイズは900KBです。

 
$ ab -n 100000 -c 100 http://対象WebサーバのIPアドレス/index.html

ベンチマーク結果

結果としては、全てのパターンで非EBS最適化インスタンスよりEBS最適化インスタンスのほうが高いパフォーマンスが得られました。やはりEC2-EBS間のネットワークスループットは、他のネットワークトラフィックの影響を大きく受けてしまうようです。

Bandwidth(KB/s)

R/W Standard Optimized
Seq Read 50802 89110
Seq Write 3799.9 10315
Rand Read 1791.6 2379.5
Rand Write 5431.8 10426

BW

IOPS

R/W Standard Optimized
Seq Read 3175 5569
Seq Write 237 644
Rand Read 111 148
Rand Write 339 651

IOPS

まとめ

知識としては理解していたところなのですが、実際に手で試すと改めて理解出来ました。通信量の多いシステムではEBS最適化インスタンスに設定するだけでも効果がありますので、簡易なスケールアップの手段として使えますね!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.